1. Field of the Invention
This invention relates to peer-to-peer networking, and more particularly to a peer-to-peer computing infrastructure for allowing devices with limited resources (e.g. small and/or wireless devices) to participate in a peer-to-peer networking environment.
2. Description of the Related Art
The Internet has three valuable fundamental assets—information, bandwidth, and computing resources—all of which are vastly underutilized, partly due to the traditional client-server computing model. No single search engine or portal can locate and catalog the ever-increasing amount of information on the Web in a timely way. Moreover, a huge amount of information is transient and not subject to capture by techniques such as Web crawling. For example, research has estimated that the world produces two exabytes or about 2×1018 bytes of information every year, but only publishes about 300 terabytes or about 3×1012 bytes. In other words, for every megabyte of information produced, only one byte is published. Moreover, Google claims that it searches about only 1.3×10^8 web pages. Thus, finding useful information in real time is increasingly difficult.
Although miles of new fiber have been installed, the new bandwidth gets little use if everyone goes to one site for content and to another site for auctions. Instead, hot spots just get hotter while cold pipes remain cold. This is partly why most people still feel the congestion over the Internet while a single fiber's bandwidth has increased by a factor of 10^6 since 1975, doubling every 16 months.
New processors and storage devices continue to break records in speed and capacity, supporting more powerful end devices throughout the network. However, computation continues to accumulate around data centers, which have to increase their workloads at a crippling pace, thus putting immense pressure on space and power consumption.
Finally, computer users in general are accustomed to computer systems that are deterministic and synchronous in nature, and think of such a structure as the norm. For example, when a browser issues a URL (Uniform Resource Locator) request for a Web page, the output is typically expected to appear shortly afterwards. It is also typically expected that everyone around the world will be able to retrieve the same page from the same Web server using the same URL.
The term peer-to-peer networking or computing (often referred to as p2p) may be applied to a wide range of technologies that greatly increase the utilization of information, bandwidth, and computing resources in the Internet. Frequently, these p2p technologies adopt a network-based computing style that neither excludes nor inherently depends on centralized control points. Apart from improving the performance of information discovery, content delivery, and information processing, such a style also can enhance the overall reliability and fault-tolerance of computing systems. The peer-to-peer model offers a compelling and intuitive way for users to find and share resources directly with each other, often without requiring a central authority or server.
FIGS. 1A and 1B are examples illustrating the peer-to-peer model. FIG. 1A shows two peer devices 104A and 104B that are currently connected. Either of the two peer devices 104 may serve as a client of or a server to the other device. FIG. 1B shows several peer devices 104 connected over the network 106 in a peer group. In the peer group, any of the peer devices 104 may serve as a client of or a server to any of the other devices.
The peer-to-peer (p2p) computing model lends itself to the dynamic environments of wireless devices including, but not limited to, cell phones, pagers, PDAs, and other consumer devices. Characterized by their ability to create, join, and interact with peer groups, and to offer and solicit resources, p2p applications may dynamically find what they need—an approach suited to the wireless environment. The p2p model is particularly interesting to wireless developers because it may enable the assembly of ad hoc networks quickly, without imposing configuration chores on users. In the wired world, networking is somewhat stable and dependable. Wireless networking is typically less reliable because it is subject to the vagaries of electromagnetic wave propagation, interference, and battery exhaustion. Devices may come and go without warning or visible reason. Peer-to-peer networking provides a model that is well suited to the vicissitudes of wireless devices.
A characteristic of wireless devices is the limited set of resources of the devices. Resource constraints of wireless devices include, but are not limited to: limited persistent storage, which may be shared by two or more applications; limited runtime heap; limited network bandwidth, with potentially high latency; limited processor performance; and potential power limitations, since wireless devices are typically battery-operated. These constraints may limit the kinds of applications that wireless devices can host independently. Because wireless devices have the ability to communicate with other systems, however, wireless devices offer potential in their ability to act as portals into networks where more comprehensive computing and storage resources can be found. Thus, wireless devices may rely on other, less constrained devices or networks of devices to get much of their work done.
Peer-to-peer computing, embodied by applications like Napster, Gnutella, and Freenet, has offered a compelling and intuitive way for Internet users to find and share resources directly with each other, often without requiring a central authority or server. As much as these diverse applications have broken new ground, they typically address only a single function, run primarily only on a single platform, and are unable to directly share data with other, similar applications.
Many prior art peer-to-peer systems are built for delivering a single type of service. For example, Napster provides music file sharing, and Gnutella provides generic file sharing. Given the diverse characteristics of these services and the lack of a common underlying p2p infrastructure, each p2p software vendor tends to create incompatible systems—none of them able to interoperate with one another. This means each vendor creates its own p2p user community, duplicating efforts in creating software and system primitives commonly used by all p2p systems. Moreover, for a peer to participate in multiple communities organized by different p2p implementations, the peer must support multiple implementations, each for a distinct p2p system or community, and serve as the aggregation point.
Many p2p systems today offer their features or services through a set of APIs that are delivered on a particular operating system using a specific networking protocol. For example, one system might offer a set of C++ APIs, with the system initially running only on Windows, over TCP/IP, while another system offers a combination and C and Java APIs, running on a variety of UNIX systems, over TCP/IP but also requiring HTTP. A p2p developer is then forced to choose which set of APIs to program to, and consequently, which set of p2p customers to target. Because there is little hope that the two systems will interoperate, if the developer wants to offer the same service to both communities, they have to develop the same service twice for two p2p platforms or develop a bridge system between them. Both approaches are inefficient and impractical considering the dozens of p2p platforms in existence.
Many p2p systems, especially those being offered by upstart companies, tend to choose one operating system as their target deployment platform. The cited reason for this choice is to target the largest installed base and the fastest path to profit. The inevitable result is that many dependencies on platform-specific features are designed into (or just creep into) the system. This is often not the consequence of technical desire but of engineering reality with its tight schedules and limited resources.
This approach is clearly shortsighted. Even though the earliest demonstration of p2p capabilities are on platforms in the middle of the computing hardware spectrum, it is very likely that the greatest proliferation of p2p technology will occur at the two ends of the spectrum—large systems in the enterprise and consumer-oriented small systems. In fact, betting on any particular segment of the hardware or software system is not future proof.
Java™ may be used to implement platform-independent applications for wired and/or wireless Web environments, small business environments, large enterprise environments, and other environments. Incompatibilities that may result from the many vendors of mobile devices may be mitigated by the unifying force of the Java programming language. Recognizing that some tailoring was required to more carefully match Java environments to their target platforms, Sun Microsystems has worked with the developer community to regroup its Java technologies into three editions: Standard (J2SE™ technology), Enterprise (J2EE™ technology), and Micro (J2ME™ technology). J2ME specifically addresses the consumer space that covers a range of smaller platforms that include smart cards, pagers, set-top boxes, and wireless devices. Like all Java editions, the J2ME platform maintains the qualities critical to Java, including portability of code, safe network delivery, and upward compatibility with J2SE and J2EE platforms. J2ME includes special profiles designed to support the limited resources of smaller devices. The Connection Limited Device Configuration (CDLC) and Mobile Information Device Profiles (MIDP) are core class libraries and specialized APIs designed to work in the constrained environments of wireless devices. Despite their small size, CDLC and MIDP offer developers the tools they need to create powerful wireless applications that can interoperate with Java solutions running on workstations, servers, and mainframes. CLDC targets small, resource-constrained devices, such as mobile phones, personal digital assistants, and small retail payment terminals. CLDC is suitable for devices with 16/32-bit RISC/CISC microprocessors and controllers with as little as 160 KB of total memory. MIDP-1.0 is a set of Java APIs that are targeted at mobile information devices, such as cellular phones and two-way pagers. The MIDP-1.0 specification addresses issues such as user interface, storage persistence, networking, and application model.
At least some characteristics of peer-to-peer systems used in peer-to-peer networking environments may make it difficult to implement the peer-to-peer systems on many wireless devices, including Mobile Information Device Profile (MIDP) devices, which may be operating under the constraints described above. For example, peer-to-peer messages may be in a markup language (e.g. XML) or other format that may require a parser to translate. Although it may be possible to parse such messages in wireless devices, including MIDP devices, a parser may push the memory limits of such devices. In addition, on peers implementing a peer-to-peer platform, the state of the network may need to be cached on peers, which means that advertisements for peers and other peer-to-peer platform entities (e.g. peer groups, services, communications channels (pipes), etc.) must be saved, further straining the limited memory wireless and/or small devices, including MIDP devices, afford. Further, peers implementing a peer-to-peer system may listen for incoming network information at the stream and Datagram level. MIDP mandates support for HTTP, but socket and Datagram connections are optional.
Thus, it is desirable to provide a mechanism for applications on wireless devices, such as MIDP devices, to participate as peers in peer-to-peer network environments. Due to the resource constraints typical of many wireless devices, it is also desirable for this mechanism to be conservative in the usage of resources of the wireless devices, while still providing access to the peer-to-peer functionalities typically available to other peers in peer-to-peer network environments.